To smooth impact brought by network transmission and synchronize play at a transmit end with that at a receive end, an audio/video application on a current Internet Protocol (IP) network uses a buffer at the receive end in order to smooth impact of network jitter on the application. Furthermore, the receive end needs to temporarily store received data in the buffer, and provides a user with audio/video data according to a decoding demand. Such a buffer is referred to as a de-jitter buffer, which ensures that audio/video can be continuously played after being transmitted on the network. Design of the de-jitter buffer needs to comprehensively consider a delay and a packet loss that are brought by buffering. An undersized buffer may cause excessive packet losses, and an oversized buffer may cause a long play delay.
Voice over Internet Protocol (VoIP), which is a real-time voice communications technology based on an IP network, has been widely used in recent years. The VoIP has advantages such as a low call cost, a small occupied bandwidth, and provision of various multimedia services, and is a research focus in the current computer network and communications fields. Factors that affect voice quality of the VoIP mainly include a delay, a packet loss, and jitter, and the jitter is mainly processed using the de-jitter buffer at the receive end. The de-jitter buffer can effectively absorb network jitter, and reduce a packet loss rate. Performance of the de-jitter buffer directly affects the voice quality of the VoIP. If an excessively large size is set for a de-jitter buffer, a voice delay increases accordingly. If an excessively small size is set for a de-jitter buffer, delay jitter cannot be absorbed, which causes an increase in a voice packet loss rate. Therefore, setting of the de-jitter buffer needs to balance the delay and the packet loss rate.
An existing de-jitter buffer modeling algorithm is dedicated for a real-time transport protocol (RTP) or user datagram protocol (UDP) scenario in which a delay of each received RTP packet is calculated using arrival time, a time stamp, and a sequence number of the RTP packet, and it is further determined whether the packet belongs to a network-lost packet, an actively discarded packet, or a normal packet. However, the de-jitter buffer modeling algorithm does not consider a transmission control protocol (TCP) scenario, such as progressive download (PD) or dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH). Because data transmission in the TCP scenario has a feature completely different from that in the UDP scenario, the existing de-jitter buffer modeling algorithm dedicated for UDP cannot be used to determine a buffer status of user equipment (UE) in the TCP scenario. Therefore, how to determine the buffer status of the UE in the TCP scenario, and in particular, how to determine a media period of time during which data received by the UE can be continuously played is an urgent technical problem to be resolved.